Memory error conditions can generate disastrous results where a user is required to reset the system causing critical data from a run-time to be lost. Memory error conditions such as single and double-bit memory errors may be detected by an Error Correction Code (ECC) logic path in a memory controller.
One approach currently taken for run-time recovery is to have the memory controller seek execution of recovery code in order to recover the run-time. An operating system, for example, may be prepared to enable disaster recovery in response to memory error conditions by executing recovery code. Current operating systems, however, are constrained to having the recovery code execute within the main memory. This may be problematic if the section in main memory that is used to execute the recovery code is the same section that is experiencing memory error conditions and requires servicing itself.
Another approach that is taken for run-time recovery is to implement a service processor with a main memory independent flow for run-time recovery. Upon successful invocation of the service processor, run-time recovery may be possible. Implementing a service processor on a platform, however, requires additional space which may not always be available. Furthermore, adding a service processor would require additional costs which is not desirable.
Thus, what is needed is an effective method and apparatus for enabling run-time recovery of a failed platform.